home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / mmdf / mmdf43_docs / review / p8 < prev    next >
Encoding:
Text File  |  1986-02-01  |  3.9 KB  |  82 lines
  1. .SH
  2. The BBOARDS Channel
  3. .PP
  4. Sites that run the MH message system, version mh.5, may install
  5. a \fIbboards\fR channel which delivers messages 
  6. from interest-group mailing lists to a special ``bboards'' directory  .
  7. The bboards software,
  8. which is compatible with the MH message system, keeps track of which
  9. messages have been seen by individual users, and allows designated bboards
  10. managers to control the size and access for different bboards.
  11. .FN
  12. See the \fIman\fR entry mh-gen.8 in the MH distribution.
  13. It is important to note that the choice to install ``bboards'' 
  14. must be made when MMDF is generated.  The ``news'' facility mentioned
  15. in the MH documentation is not supported by CSNET.
  16. .FE
  17. .SH
  18. The UUCP Channel
  19. .PP
  20. The task of integrating UUCP mail into MMDF was a prime
  21. goal for BRL.
  22. Our users would not tolerate having to use
  23. two radically different mail interfaces for two different
  24. kinds of mail connections.
  25. We decided to write a channel to interface to the UUCP
  26. mail world that would take care of the necessary format
  27. conversions to allow mail to traverse the two mail worlds.
  28. The channel has two parts.  The input portion of the channel
  29. is the program \fB/bin/rmail\fR which is executed by the UUCP
  30. program \fBuuxqt\fR when mail is being delivered.
  31. The output portion is a standard channel that invokes the UUCP
  32. system after reformatting the message.
  33. .PP
  34. The \fBrmail\fR
  35. program has been totally rewritten to interface to MMDF.
  36. \fBRmail\fR's primary task is to collect and reformat the
  37. address strings in the message.
  38. To reformat each address, \fBrmail\fR uses the UUCP channel table
  39. to determine what hosts are known to this host and shortens
  40. an host!host!host! string down to the single most distant host we know
  41. about and any subsequent hosts we do not know.  For example
  42. knownA!knownB!knownC!unknown1!unknown2!user would become
  43. knownC!unknown1!unknown2!user.
  44. It then converts this to an RFC822 style address by putting the unknown
  45. hosts and the user in the local part and putting the known host with
  46. a domain in the domain portion, e.g. unknown1!unknown2!user@knownC.UUCP.
  47. If all the hosts are known, then only the user
  48. is left in the local part, and the address winds up being user@known.UUCP.
  49. Since you always know the hosts you talk to, you can build any arbitrary
  50. UUCP path by simply saying arbitrary-host-path@neighbor.UUCP.
  51. .PP
  52. \fBRmail\fR is prepared to accept destination addresses in two forms.
  53. If the addressee is just another UUCP host addressed using host!host!...
  54. notation, then \fBrmail\fR forwards the letter via UUCP without header munging
  55. since the destination host may not support RFC822 style mail.
  56. An addressee of the form user@domain will
  57. cause the message to be fed to \fBsubmit\fR and into MMDF proper
  58. where the message can be delivered to another UUCP site or any other site
  59. accessible via MMDF.
  60. \fBRmail\fR will reformat the message header in the latter case to conform
  61. as much as possible with the RFC822 specifications.
  62. .PP
  63. The outbound portion of the UUCP channel is a MMDF channel program called
  64. ``uucp'' which is invoked by \fBdeliver\fR.
  65. The job of this program is much
  66. easier since all it must do is reformat the ``From:'' line to be compatible
  67. with UUCP mail.
  68. The outbound channel must also reformat the destination addresses
  69. which become arguments to \fBuux\fR.
  70. The outbound channel uses the same channel table that
  71. \fBrmail\fR used but performs the reverse action on the address so,
  72. for example, root@mcnc.UUCP becomes unc!duke!mcnc!root and this is
  73. then further divided to form the uux command
  74. ``uux unc!rmail duke!mcnc!root'' (assuming the channel table maps
  75. mcnc.UUCP into duke!unc!mcnc).
  76. .PP
  77. The UUCP channel would have to be classed as the only ``flakey''
  78. portion of MMDF since some of these address transformation really need
  79. an advanced AI system to make an intelligent transformation.
  80. In general, though, the channel does a very good job and has little trouble
  81. with ``normal'' UUCP addresses.
  82.